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L'invention concerne un precede de reconnaissance et d'analyse 
de communications reseaux, tels que Ethernet, TCP/IP,... 

L'invention est utilisable, par exemple, pour la mise en oeuvre de 
5 chaTnes integrees d'acquisition, d'analyse et de renseignement. Elle permet 
d'assurer en temps reel toutes les fonctions complementaires de la 
surveillance active et passive d'un reseau : 

• profilage des communications, reseaux et utilisateurs ; 

• aide au datamining ( equivalent en Frangais de "extraction, indexation et 
10 exploration semantique') des informations transitant sur un reseau ; 

• aide au monitoring (equivalent frangais de controle et audit) et a la 
detection d'intrusion. 

Elle s'applique notamment pour I'ecoute de flux securises. 

15 En regie generate dans un systeme de surveillance d'un reseau, 

on cherche, a Taide d'un analyseur, a extraire du flux de trames ecoute 
certaines informations significatives des utilisateurs emettant et recevant le 
flux. L'approche evidente et connue pour cette operation est de presupposer 
que le flux repond a un des modeles reseaux existants. Des lors, chaque 

20 trame est isolee, puis I'analyseur en remonte les couches de fagon 
systematique. Si cette methode offre une certaine simplicity, elle presente 
toutefois certaines limites, notamment : 

• rimpossibilite d'analyser des flux contenant des protocoles non 
conformes aux standards ou aux normes ; 

25 • la non restitution des flux, Tanalyse de chaque trame etant prise 
independamment. 

Les fonctionnalites des produits existants, tels que les analyseurs 
reseau : par exemple Ethereal (Ethereal est le nom d'un logiciel libre sous 
license publique GPL), Surveyor marque deposee par la societe Shomiti, se 

30 limitent a I'identification simple de paquets isoles transitant sur le reseau. 
S'ils s'averent performants, ils ne prennent toutefois pas en compte la notion 
de flux (lecture de champs, sans gestion du comportement de ('application en 
emission/reception des donnees ou de la diffusion d'information entre 
plusieurs paquets dans la plupart des cas). Par consequent, I'acces au 



1er depot 



2 

contenu, c'est a dire Pacces aux donnees de Putilisateur transmises dans ie 
flux par !es applications a Paide du protocole IP, est \\rn\te. 

□'autre part, !es produets existants analysent les paquets de !a 
menne fagon que les piles de protocole standard. Us ne possedent done 
5 aucune capacite d'adaptation a des situations non-standard ni aucune 
Intelligence' dans Se traitement. Les automates n'ont pas de capacites de 
synthese ou consolidation de information. Cette fonction est laissee a 
Papplicataon utilisatrice, c'est a dire au dessus des protocoles. Sous 
('expression « non standard » on entend, dans le contexte de la presente 
10 description, des applications specifiques utilisant des versions modifiees de 
protocoles, restant routables sur les reseaux IP (Internet Protocol) mais 
n'etant pas interoperables avec d'autres applications. 

L'invention propose une nouvelle approche qui repose notamment 
15 sur une analyse globale des flux (flux de trames des donnees echangees 
dans un reseau). 

Pour cela elle permet une analyse des communications dans un 
reseau a Pechelle de flux entiers, en mettant en oeuvre des 
principes notamment : 
20 d'analyse en largeur couche par couche, par exemple, dans le modele 
TCP/IP et non paquet par paquet ; 
© de caracterisation statistique des flux, incluant une analyse semantique 
des variantes de protocole et une anaSyse comportementale de la 
dynamique des echanges. 

25 

(.'invention concerne un procede d'analyse des flux de donnees 
dans un reseau de communication modelise par plusieurs couches. II est 
caracterise en ce qu'il comporte au moins les etapes suivantes : 
• capturer un flux de donnees, 
30 • pour une couche du reseau donnee, analyser la globalite du flux afin de 
determiner le ou les protocoles presents, 
© produire differents flux correspondant a au moins un protocole present, 
o reiterer Petape d'analyse pour une eventuelle couche superieure. 

Le procede comporte par exemple les etapes suivantes : 
35 1) analyser le paquet capture, 
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1 .a) si le paquet n'est pas reconnu, passer au paquet suivant, 
1.b) si le paquet est reconnu, supprimer le paquet du flux capture, 
rechercher un flux existant pour inserer le paquet, 
s'il n'existe pas de flux existant generer un nouveau flux, 
5 2) analyser les flux generes a I'etape 1), 
3) liberer les ressources. 

L'analyse globale des flux est par exemple realisee a I'aide de 
tests d'analyse statistique ou protocolaires. 

Le precede s'applique pour analyser des donnees dans un reseau 
10 ayant le protocole TCP/IP. 

L'invention concerne aussi un dispositif d'analyse de flux de 
donnees dans un reseau de communications pouvant etre modelise par 
plusieurs couches caracterise en ce qu'il comporte au moins un processeur 
adapte a mettre en oeuvre le procede tel que decrit ci-dessus. 
15 ..;« 
L'invention presente notamment les avantages suivants : 

• Elle s' adapte a differentes structures de flux IP, standards ou non, avec la 
discrimination entre les flux securises et les flux non proteges a tous les 
niveaux de la pile (reconnaissance clair/chiffre), 

20 • Elle permet la recherche d'informations de nature cryptographique, dont 
la reconnaissance du type d'algorithmie permettant d'assurer les services 
de confidentialite et d'integrite (pour des standards de chiffrement par 
blocs, tels que AES (ADVANCED ENCRYPTION STANDARD), 
DES (DATA ENCRYPTION STANDARD ) pour des standards de fonction 

25 de hachages, par exemple SHA (Secure Hash Algorithm), MD5 (Message 
Digest 5), 

• Elle produit des rapports d'audits synthetiques directement exploitables 
par un administrateur ou un officier de securite. Ces rapports sont par 
exemple fournis en recapitulant les regies generees pour les flux et 

30 paquets, presentees dans une synthese sous un format lisible par un 
operateur, et filtrable eventuellement en fonction de certains criteres 
d'affichage. 
Elle offre : 

• Une identification evolutive : la possibility de s'adapter a la 
35 reconnaissance de protocoles non-standards (analyse de structures), 
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o Une architecture ouverte : ennchissement in situ de I'outil par ajout de 

composants dedies a un nouveau protocole ou a une nouveSIe 

methode d'anaSyse, 
© La capacite d'analyser des flux contenant des protocoles seulement 
5 partiellement conformes aux standards ou norrnes, ou des systemes 

de protocoles utilisant des structu rations en couches specifiques, 
© L'orientation de Tanalyse sur les flux et non sur les trames, ce qui 

permet d'obtenir des informations sur les automates lies aux 

protocoles et sur ies comportements applicatifs, 
10 • Chaque etape de traitement est independante des etapes passees ou 

futures, ce qui permet de prendre en compte tous les types de 

protocoles et la possibility decapsulation independamment de la 

complexity du flux reseau analyse. 



15 D'autres caracteristiques et avantages de I'invention apparaTtront 

mieux a la lecture de la description qui suit d'un exemple de realisation non 
limitatif annexe des figures qui represented : 

® La figure 1 un exemple de representation de I'arbre protocolaire mis en 

ceuvre pour ('invention, 
20 © La figure 2 un exemple de modele simplifie de Tarchitecture de traitement, 
® La figure 3 un diagramme de sequence sur le tri des paquets, 
® La figure 4 un exemple de resultat obtenu par la mise en oeuvre du 

procede selon ['invention. 

25 L'idee mise en oeuvre dans le procede selon I'invention repose 

notamment sur I'utilisation des methodes de reconnaissance semantique et 
statistique permettant la caracterisation des protocoles de la pile TCP/IP 
(Transmission Control Protocol/internet Protocol). 

LMnvention se caracterise par la nouvelle approche suivante, dans 

30 le cas d'un fonctionnement normal aucune hypothese n'est faite sur la 
structure en couche des trames. Au contraire, celle-ci est deduite, par 
exemple, d'une analyse des trames a la recherche de motifs representatifs 
decrits dans des signatures de protocoles. Ainsi, I'invention analyse la 
globalite du flux en essayant de determiner le ou les protocole(s) de plus bas 

35 niveau present(s) (par exemple physique). Le flux est alors separe en 
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fonction des protocoles identifies et Tanalyse est reiteree pour une eventuelle 
couche superieure. Au fur et a mesure que la structuration en couche est 
retrouvee, le flux dans son ensemble est verifie et decoupe en fonction des 
couches reconnues. 

5 

De maniere a mieux faire comprendre les etapes du procede 
selon invention, I'exemple donne concerne Tanalyse de flux de donnees 
dans le cadre du protocole TCP/IP, au sein d'un analyseur adapte 
comportant un processeur programme pour executer les etapes du procede, 
10 ceci a titre illustratif et nullement limitatif. 
Modele general des traitements 

La figure 1 schematise un exemple d'arbre protocolaire selon 
Tinvention representant les flux analyses. Les etapes du procede consistent 
notamment a : 

15 • construire un arbre protocolaire representant les flux analyses; un -noeud ~ 
de I'arbre correspond aux parametres caracteristiques d'un flux analyse ^ 
et une branche a la representation des flux traites, v - u # 

• effectuer un parcours en largeur de I'arbre afin d'en extraire ['information 

pertinente, a savoir Tidentification : des trames (adresses IP), des * 
20 services fournis par la couche de reseau (option IP de routage, par * 
exemple pour demander au reseau un routage specifique plutot que de 
laisser les routeurs decider d'eux-meme de Titineraire emprunte), des k 
evenements speciaux ou inhabituels (renouvellement de cle de 
chiffrement, rupture de flux, attaque en rejeu sur un flux chiffre), 
25 autrement dit le contenu des regies. 

Les etages de I'arbre protocolaire correspondent par exemple aux 
couches reseau de la pile TCP/IP : la couche physique 1, la couche reseau 
2, la couche transport 3, la couche application 4. La racine 5 de I'arbre 
protocolaire correspond au niveau ou est realisee la capture de flux. Par 
30 exemple, dans le cas d'un flux Ethernet la racine est au niveau physique 
(couche physique 1). 

Dans un flux reseau, I'information est vehiculee dans des 
structures elementaires appelees 'trames'. Ces trames sont emises une a 
35 une sur le lien physique, chacune de fa?on independante. En fonction du 



1er depot 



3 

medium utilise pour !a circuSaHion de ('information, 8a trame peut etre 
precedes de silences et/ou de preambules de synchronisation : ces signaux 
lies au medium existent pour des considerations de traitement de signal. 
Dans Sa terminologie reseau, un bloc dlnformation transfere prend un nom 
different suivant la couche OSI qui le manipule : au niveau physique on parte 
de trame, au niveau reseau de paquet ou de datagramme. Le niveau 
transport manipule des segments, et au niveau application on considere des 
messages. Les termes trame et paquet designent une meme entite de 
donnees. 

Les flux consideres par le procede selon I'invention sont, par 
exemple, des sequences de trames epurees des signaux lies au medium. 

Un flux de donnees est divise en : 
© Un nombre variable de paquets (chaque paquet represente une trame 
reseau), 

© Un nombre variable de regies (initialement aucune, les regies sont creees 
par le moteur d'analyse comme il est decrit ci-apres). 

Chaque trame possede une structure interne qui correspond a un 
systeme stratifie : les reseaux sont bases sur des modeles en couches. Les 
deux modeles de reseaux existant actuellement sont le modele normalise 
OSI de PISO et le systeme de protocoles standardises TCP/IP. Le principe 
d'un modele en couche est de decomposer I'ensemble des traitements de 
transmission/reception en plusieurs modules representant une couche et 
ayant chacun un role precis. Ces modules executent leurs taches specifiques 
en sequence. 

Les donnees ou paquets d'informations qui circulent sur le reseau 
sont traites successivement par chaque couche, selon un ordre fixe. Chaque 
couche du modele possede un niveau d'abstraction specifique (par exemple : 
lien physique, flux de transport, session d'application...) et communique avec 
les couches de niveaux d'abstraction adjacents. Ceci correspond a la notion 
de couche 'inferieure' et de couche f superieure\ Chaque couche utilise ainsi 
les services des couches inferieures et fournit des informations a la couche 
de niveau superieur. 
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couche 


Niveau 
cTabstraction 


Fonction 


1 


physique 


definit la fagon de laquelle les donnees sont 
converties en signaux electriques, 
optiques... 


2 


reseau 


permet de localiser une machine dans un 
reseau et de gerer le routage entre deux 
machines. 


3 


transport 


chargee du transport des donnees entre 
une application cliente et une application 
serveur 


4 


Application 


assure ('interface avec les applications 



L'information que Ton souhaite echanger par le reseau est par 
exemple une donnee d'application, c'est a dire une information brute de 
5 I'utilisateur (fichier stocke sur un disque, texte d'un courrier electronique, son 
et video d'une visioconference...). Cette information est traitee 
successivement par toutes les couches du modele depuis ('application 
(couche 4 dans I'exemple ci-dessus) jusqu'au niveau physique (couche 1). 
Chaque couche de I'emetteur de la trame produit au cours de son traitement 
10 des informations destinees a la couche correspondante du recepteur (par 
exemple des informations de detection d'erreur de transfer!, accuses de 
reception...)- 

A remission, ces informations sont regroupees dans un bloc 
structure appele 'en-tete 1 selon un 'protocole' donne. Cet en-tete est rajoute 

15 au bloc de donnees re<?u du niveau superieur, puis Tensemble est transmis 
au niveau inferieur. 

En reception, Pen-tete est extrait du bloc de donnees regu du 
niveau inferieur et est consomme, c'est a dire utilise par le niveau courant 
pour determiner le service a fournir (autrement dit : savoir comment traiter le 

20 contenu du bloc et a quel service le donner apres). Finalement, Ten-fete est 
detruit et reformation restante (les donnees du bloc sans Ten-fete) est 
transmise au niveau superieur pour traitement. 
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De ceite fa?on, une trame est une succession d'en-tetes de 
protocoJes, chacun etant suivi par la donnee applicative 'utilisateur'. 

La figure 2 modelise de maniere simplifiee un exemple 
d'architecture de traitement du flux selon Tinvention. Les conventions 
5 utilisees dans cette figure 2 son! issues du modele UML (Unified Modeling 
Langage : langage unifie de moderation d'objets). Le modele UML est 
normalise et edite par un groupement baptise OMG (Object Management 
Group). 

Le precede selon I'invention ou application est partage entre un 
10 processus de supervision 10 et un moteur d'analyse 11 de flux qui se 
repartissent les traitements. 

Le processus de supervision 10 est controle par I'environnement 
d'exploitation a travers une interface externe 12. II traite un flux parmi la liste 
des flux captures, materialise par le lien 10 <^> 13 et en constitue une 
15 representation a travers : 

© Une sequence de paquets 15 issue des paquets 16 du flux 13. Par 
definition, 13 est une liste de paquets 16. Le superviseur, lorsque les 
paquets sont elimines d'un flux, les garde dans une sequence 15 en 
attendant de les inserer dans un nouveau flux. 
20 © Un arbre protocolaire qui positionne les flux entre eux a I'aide des 
relations entre noeuds 17 correspondants de Tarbre. Chaque nceud pointe 
par ailleurs sur les regies 18 du flux 13. Le lien entre 10 et 17 represente 
le lien permettant au superviseur de se deplacer dans Tarbre. C'est 
initialement le lien entre le superviseur et la racine, et au fur et a mesure 
25 que de nouveaux noeuds sont crees, le superviseur se deplace. Le lien 
entre 17 et 18 permet d'attacher les regies a un flux. Le contenu de la 
regie est, par exemple, une suite de couples {nom = valeur} telle que par 
exemple « Adresse Source=d,C0A80001 » (un exemple detaille est 
donne en fin de la description). Ces couples sont fournis par la signature 
30 du protocole : chacun est le resultat de I'application d'un 'test' ou 'filtre' 
dedie, la collection de tous les filtres et leur ordre d'enchaTnement 
constituant la signature. Par exemple ici, il existe dans la signature du 
protocole IP un filtre ^ adresse_source , qui, applique a un paquet, renvoie 
le message ci-dessus. 
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Le moteur d'analyse 1 1 de flux lit a un moment donne un fichier 1 3 
de flux en provenance de la supervision et peut en creer un nombre variable. 
Ces derniers sont ajoutes a la liste des flux manipules. Le moteur d'analyse 
de flux peut charger en memoire de facon dynamique un nombre variable de 
filtres 14 (par exemple sous forme de DLLs, ou Dynamic Link Library) qui lui 
permettent de traiter le flux considere. Les filtres sont par exemple des filtres 
semantiques et statistiques discriminants et caracterisant un protocole. 

La figure 3 represente un exemple de diagramme de sequence 
sur le tri des paquets contenus dans les frames vehiculees par le medium. 
Ce tri est effectue par le processus appele 'moteur', 

• qui accepte en parametre : 

• un fichier de capture de flux reseau, comportant par exemple 
une sequence de paquets IP, 

• un niveau de traitement (couche du modele TCP/IP a traiter) ; 
cette information est donnee par I'operateur. Par exemple 
IMHM (Interface Homme Machine) demande a I'operateur le 
nom du fichier de capture puis lui propose une liste de niveaux 
parmi laquelle il choisit, 

• un arbre protocolaire, initialement 'vide', c'est a dire reduit a 
une racine situee au niveau de traitement selectionne. En 
d'autres termes, I'on initialise le systeme en lui donnant une 
racine definie en fonction du numero de couche precedemment 
choisi. 

et 

• qui fournit en sortie I'arbre complete, c'est a dire assortit de nouvelles 
branches assurant la representation des flux traites. 

Sur le diagramme de la figure 3 les differentes etapes du procede 
permettant de construire les nouvelles branches de I'arbre sont par exemple 
et en resume les suivantes : 

0 - Le superviseur envoie un ordre de traitement d'un flux capture, . 
Phase 1 

1 - le moteur lit le paquet, analyse le paquet a I'aide des filtres charges puis 
selon le resultat des filtres (decision 'reconnu' ou 'non-reconnu'), 

1a - Si le paquet n'est pas reconnu, le moteur passe au paquet suivant, 
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1b - Si le paquet est reconnu le moteur supprime le paquet du flux et 
recherche un flux existant pour inserer le paquet reconnu. Dans le cas ou le 
moteur ne trouve pas de flux existant, alors il genere un nouveau flux dans 
Sequel il insere le paquet. Enffin, le moteur passe au paquet suivant. 
5 On teste un paquet pour chaque protocole (done pour chaque signature, 
e'est a dire un ensemble de filtres) jusqu'a obtenir une decision 'reconnu'. 
Par exemple, en transport, si on charge les filtres UDP (User Datagram 
Protocol) puis les filtres TCP (Transmission Control Protocol), on va d'abord 
appliquer au paquet les filtres UDP. Si la reponse est 'reconnu', on le met 
10 dans un flux approprie et on passe au paquet suivant. Si 'non-reconnu', on 
recommence avec les filtres TCP... 

Si TCP dit alors 'non-reconnu', le paquet reste dans le flux et on passe au 
paquet suivant. 

Pna se 2 = A Tissue de la phase 1 le procede possede un ensemble de flux 
15 qu'il analyse globalement a I'aide des filtres charges. Les differents flux 
constituent les differentes branches de I'arbre. 

Apres avoir realise I'etape 1, le flux d'origine est reduit : tous les paquets 
reconnus ayant ete extraits et deplaces (ou regroupes) dans d'autres flux. II 
n'y reste que des paquets non reconnus, voire aucun paquet. On se retrouve 
20 done avec un flux d'origine 'reduit' et une serie de nouveaux flux 'fils'. Ces 
flux sont dits 'regroupes'. 

Phase 3 = la liberation des ressources - on decharge tous les filtres et on 
libere toute la memoire qu'ils auraient pu utiliser. 

II existe par exemple deux types de filtres, les filtres en mode 

25 paquet et ceux en mode flux. Les premiers servent a dire si le paquet est 
'reconnu' ou 'non-reconnu' pour le protocole et permettent de donner un 
identifiant (en resume relativement a I'exemple en fin : le nom qui sert a 
renommer le flux et le fichier enregistre sur le disque, comme par exemple 
"IP_COA80001_COA80064,UDP_01F4_01F4"). En mode flux, on va donner 

30 des renseignements supplementaires (la regie se voit ajouter de nouveaux 
couples). Par exemple, e'est dans ce mode flux qu'un filtre va pouvoir dire 
que 'TOS = 0' et qu'un autre va etablir 'options IP = absent'. 

Le moteur utilise dans une premiere passe, cf. phase 1) du 
diagramone de sequence, les informations explicites de chaque datagramme 

35 pris independamment (identification reposant sur des signatures 
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semantiques de protocole, appelees : 'fiitres de paquets'). II n'opere aucun 
recoupement, aucune analyse statistique ou aucun traitement approfondi sur 
la nature des datagrammes mais effectue toutefois les taches de 
reassembiage des fragments IP / segments TCP. 

Lorsqu'un flux est regroupe par le processus c moteur\ c'est a dire 
chacun des flux de I'ensemble obtenu en 2) ce dernier realise en deuxieme 
passe une analyse globale, cf. phase 2) du diagramme de sequence, a Taide 
de tests d'analyse statistique ou protocolaire (litres de flux') permettant de 
discriminer les parametres utiles du protocole considere au vu du flux 
complet. 

Enfin, le processus 'moteur' epure Tarbre en collectant puis en 
supprimant les listes de datagrammes correspondant a des protocoles 
identifies sans ambiguTte. Les listes de donnees collectees, correspondant 
aux paquets qui ont ete reconnus sont fournies en sortie avec leurs 
caracteristiques. Les datagrammes de branches non identifies sont 
exportes tels quels (pour analyse eventuelle avec un autre outil compatible 
ou apres enrichissement de la base de signatures). 
Traitements detailles 

Pour determiner le protocole relatif a une couche reseau, 
Tinvention exploite une base de signatures de protocoles, une signature est 
une collection de filtres, certains par 'paquets' (ils ne traitent qu'un paquet a 
la fois), certains par 'flux 1 (ils ont besoin de tous les paquets simultanement). 
Ces signatures comprennent un ensemble de tests dont Tobjectif est triple : 

• determiner si une trame, pour la couche analysee, utilise le 
protocole signe (verdit oui / non) ; 

• determiner des informations significatives du protocole reconnu 
pour la trame (comme I'identification de I'emetteur et du 
destinataire, Tutilisations de certains modes ou options...)- Ces 
informations sont regroupees dans une regie associee au 
paquet ; 

• determiner des informations significatives du protocole pour le 
flux (comme des ruptures de sequence non conformes aux 
automates standards...). Ces informations sont regroupees 
dans une regie associee au flux ; 
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Le traiterrient d'un flux etant decompose en couches, si est 
recursif, et chaque etape de la recursivete comprend les operations suivantes 
(cf. figure 3) : 

o recuperation de la liste des protocoles susceptibles 

d'apparaTtre au niveau considere ; 
© analyse trame par frame du flux, ou chaque trame est 

confrontee sequentseilement a toutes les signatures de 

protocoles envisagees jusqu'a ce qu'un verdict positif soit 

prononce ; 

© recuperation de la regie par paquet de chaque trame 
reconnue ; 

© classification des frames en fonction des regies : toutes les 
frames ayant le meme protocole et la meme regie par paquet 
sont deplacees dans un flux distinct (un flux 'non reconnu' 
concentre le reliquat eventuel) ; 
© analyse globale de chacun des flux ainsi extraits par rapport a 
son protocole reconnu, puis association de la regie de flux 
issue de I'analyse. 
On voit que pour un flux entrant, plusieurs flux sortants peuvent 
etre generes par Hnvention : la relation de filiation entre le flux entrant et le(s) 
flux sortant(s) est enregistree sous forme d'arbre. 
Illustration du piineipe de ('invention sur un exemple 

On suppose qu'un flux de capture C contient trois frames : deux 
issues du systeme de protocole TCP/IP pour une application non signee ; et 
une trame issue d'un modele non IP. Ce flux est produit et enregistre sous la 
forme suivante : 

Trame 1 = lP(a^>b)/TCP(s^d)/? 
Trame 2 = IP(a->b)/TCP(s^e)/? 
Trame 3 = ? 

ou la convention de representation est : 

les protocoles sont listes de gauche a droite depuis le plus bas 
niveau vers Se plus haut ; 

le protocole signe P specifiant renvoi de donnees depuis sa 
source S vers ia destination D est note par P(S->D) ; 

un protocole non reconnu est note ? 



1 er depot 



13 

On suppose egalement dans I'exemple que I'invention est 
instrumentee des protocoles suivants : 
Couche 2 reseau : IP ; 
Couche 3 transport : UDP, TCP ; 
Couche 1 application : HTTP. 

On precise que le premier protocole suppose present est un 
protocole de reseau. 

Initialement, le precede selon I'invention considere le flux C 

comme : 
Trame 1 = ? 
Trame 2 = ? 

Le moteur charge la signature du protocole IP et I'applique a la 

trame 1 . 

Le verdict est positif et la regie associee est : IPsource=a, 
IPdestination=b. 

Un nouveau flux IPab est cree : la trame 1 est supprimee du flux C 
et deplacee dans le flux IPab. 

Puis la trame 2 est confrontee a la signature de IP. Le verdict est 
positif et la regie associee est : IPsource=a, IPdestination=b. 

Comme le flux IPab pour IP associe a cette regie existe, la trame 
2 y est deplacee. 

Enfin la trame 3 est confrontee a la signature de IP. Le verdict est 
negatif, cependant I'invention ne possede pas d'autres signatures, done la 
trame 3 est laissee comme non reconnue au niveau reseau. 

Toutes les frames etant traitees, I'invention effectue ('analyse des 
flux crees : le flux IPab est confronte a la signature de IP. Le resultat est une 
regie de flux : TTL=64,options=aucune'. 

A la fin de cette etape, il existe done deux flux : 

IPab(IP :TTL=64,options=aucune) : 

Trame 1 = IP(a->b)/? 

Trame 2 = IP(a^-b)/? 

C : 

Trame 3 = ? 

Ces flux sont enregistres comme fils du flux C. 
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UDP et TCP etant susceptibles d'apparaitre au niveau superieur a 
IP, l'invention precede a une nouvelle etape de traitement : 

L'invention charge la signature des protocoles UDP et TCP 

I'invention applique la signature UDP a la trame 1 . 

Le verdict est negatif, done la signature de TCP est appliquee. 

Le verdict est positif et la regie associee est ■ 
TCPsource=s,TCPdestination=d. 

Un nouveau flux IPab.TCPsd est cree : la trame 1 est supprimee 
du flux IPab et deplacee dans le flux IPab.TCPsd. 

Le procede applique la signature UDP a la trame 2. 

Le verdict negatif, done la signature de TCP est appliquee. 

Le verdict est positif et la regie associee est - 
TCPsource=s,TCPdestination=e. 

Le flux existant IPab.TCPsd ne convenant pas, un flux 
IPab.TCPse est cree : la trame 1 est supprimee du flux IPab et deplacee 
dans le flux IPab.TCPse. 

Le flux IPab.TCPsd est confrontee a la signature de TCP. Le 
resultat est une regie de flux vide. De meme pour IPab.TCPse. 
A la fin de cette etape, il existe done trois flux : 
IPab,TCPsd(IP .TTL=64,options=aucune ;TCP :vide) : 
Trame 1 = IP(a^>b)/TCP(s-^d)/? 
IPab,TCPse(IP :TTL=64,options= aucune ;TCP :vide) : 
Trame 1 = IP(a-*b)/TCP(s->e)/? 
C : 

Trame 3 = ? 

Les flux IPab.TCPsd et IPab.TCPse sont enregistres comme fils 
du flux IPab. 

Les trames de IPab ayant ete entierement consomme IPab 
dispara lt en tant que flux. Cependant, le noeud correspondant est conserve 
dans I'arbre avec sa regie de flux. 

L'invention procede a une derniere etape de traitement pour les 
deux flux venant d'etre crees. De la meme facon que pour la trame 3 la 
confrontation a la signature de HTTP echoue et les flux sont laisses 
inchanges. 
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Comme tous les flux existant ont ete traites completement, la liste 
precedente constitue le resultat final de I'analyse et Parbre protocolaire 
associe est illustre a la figure 4. 

5 Variante de realisation 

^invention decrite pour le modele TCP/IP, dont on adopte ici la 
terminologie specifique, peut etre egalement adaptee au modele OSI car les 
deux modeles presentent des similitudes fortes dues a une elaboration 
partiellement commune. 
10 Pour exemple, les couches du modele le plus complet sont 

detaillees : le modele OSL 



couche 


Niveau 

d 'abstraction 


Fonntion 


1 


physique 


definit la fa?on de laquelle les donnees sont 
converties en signaux electriques, 
optiques... 


2 


liaison donnees 


definit 1'interface avec la carte reseau et 
permet d'identifier une carte reseau parmi 
plusieurs connectees sur un meme lien 


3 


reseau 


permet de localiser une machine dans un 
reseau et de gerer le routage entre deux 
machines. 


4 


transport 


chargee du transport des donnees entre 
une application cliente et une application 
serveur 


5 


session 


definit Touverture des sessions des clients 
sur un serveur 


6 


Presentation 


definit le format des donnees (leur 
representation) 


7 


Application 


assure Tinterface avec les applications 



Le procede selon invention offre de nouveaux precedes 
15 d'analyse des communications : 
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o La reconnaissance et discrimination recursive des protocoies de la pile 
TCP/IP dont par exempie la remontee de tout type de tunnelling. 

o La reconnaissance statistique des caracteristiques des protocoies de la 
pile TCP/IP et discrimination statistique entre variantes de protocoies. 
L'invention permet notamment une discrimination entre le standard de 
securite pour IP ESP et des implementations specifiques (ex : Chiffreur IP 
THALES Mistral). 

o La possibility d'etre mise en oeuvre dans differents reseaux de 
communications pouvant etre modelises par couche. 

Afin de preciser le concept de regie utilise dans la presente 
description un exempie concret est donne ci-apres. Les choix 
d'implementation ne sont pas exclusifs de l'invention, aussi ils sont a prendre 
uniquement a titre indicatif pour une meilleure comprehension. 

En entree, on a analyse un flux de type 'UDP/IP', c'est a dire une 
communication IP envoyant des messages a travers le protocole de transport 
UDP. L'application utilisee sert a gerer les parametres de la securite pour 
IPSec (par exempie : se mettre d'accord en gre a gre sur une cle de 
chiffrement. Cette application et le protocole qui la vehiculent sont baptises 
tous deux ISAKMP. 

L'analyse 11a reconnu dans un premier temps un flux 13 IP (plus 
bas niveau protocolaire disponible dans les signatures, cf. 14) et a extrait une 
regie 18 dont le libelle est le suivant : 

"IP_C0A80001_C0A80064 : Adresse Source=d,C0A80001|Adresse Destinati 
on=d,C0A80064|TOS=p,0|Options IP=p,absent". 

(On remarquera que le format est pratiquement lisible tel quel, 
moyennant de faire les conversions hexadecimales et de connaitre quelques 
conventions internes aux regies). 

Cela etani fait, le flux a ete reanalyse au niveau transport, et un 
flux UDP a ete decouvert. Une nouvelle regie 18 est alors creee pour I'etage 
UDP: 

"UDP_01F4_01F4 : Port Source=d,01F4|Port Destination=d,01F4" 

Dans le cas present, la signature (filtres 14) qui aurait permis de 
rajouter une regie speciale sur ISAKMP n'a pas ete incluse, done il n'y a pas 
de travail supplementaire a faire sur le flux et l'analyse 1 1 s'arrete la. 
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A partir de ces deux regies, on rebaptise le flux 
"IP_C0A80001_C0A80064,UDPJ31 F4_01 F4" 

Get identifiant sert a le localiser dans I'arbre de protocole (label du 
noeud 17) et a le manipuler sous forme de fichier (via I'explorateur de 
5 Windows, on peut retrouver un fichier portant ce nom qui contient les trames 
de ce flux) 

Lorsque le prototype a fini ses analyses, il affiche a Toperateur 
une synthese (presentement en HTML) pour le flux : 

10 IP_COA80001_COA80064,UDPJ)1 F4_01 F4 : 
IP 

Definition : 

Adresse Source : 192.168.0.1 
Adresse Destination : 192.168.0.100 
15 Regie par paquet 

TOS : 0 

Options IP : absent 

UDP 

Definition 

20 Port Source : 500, Internet Security Association and Key 

Management Protocol (ISAKMP) 

Port Destination : 500, Internet Security Association and Key 
Management Protocol (ISAKMP) 

On remarque que les informations affichees correspondent 
25 litteralement au contenu de la regie. L'affichage apporte a ce contenu 'brut' le 
confort d'une presentation en tableau avec quelques comodites pour la 
lecture (comme la conversion des adresses IP depuis I'hexadecimal ou le 
nom explicite du protocole ISAKMP reconnu). 



30 



L'invention concerne aussi un analyseur de reseau comportant au 
moins un processeur adapte a executer les differentes etapes du procede 
decrit ci-dessus. 
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REVENDICATIONS 

1 - Procede d'analyse des flux de donnees dans un reseau de 
communication modelise par plusieurs couches caracterise en ce qu'il 
comporte au moins les etapes suivantes : 

o capturer un flux de donnees, 

o pour une couche du reseau donnee, analyser la globalite du flux afin de 

determiner le ou les protocoles presents, 
© produire differents flux correspondant a au moins un protocole present, 

• reiterer I'etape d'analyse pour une eventuelle couche superieure. 

2 - Procede selon la revendication 1 caracterise en ce qu'il comporte au 
moins les etapes suivantes : 

1) analyser le paquet capture, 

1.a) si le paquet n'est pas reconnu, passer au paquet suivant, 

1.b) si le paquet est reconnu, supprimer le paquet du flux capture, 

rechercher un flux existant pour inserer le paquet, 

s'il n'existe pas de flux existant generer un nouveau flux , 

2) analyser les flux generes a I'etape 1), 

3) liberer les ressources. 

3 - Procede selon la revendication 1 caracterise en ce qu'il comporte au 
moins les etapes suivantes : 

• recuperer la liste des protocoles susceptibles d'apparaTtre pour la couche 
ou le niveau considere, 

• analyser trame par trame le flux capture, en confrontant sequentiellement 
une trame a toutes les signatures de protocole envisagees, tant que la 
trame n'est pas associee a une signature, 

® recuperer la regie par paquet de chaque trame reconnue, 
o classifier les trames en fonction des regies, et les positionner dans des 
flux distincts, 

o analyser globalement les flux distincts en utilisant le ou les protocoles 
reconnus, 

© associer la regie de flux issue de I'analyse. 
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4 _ Procede selon Tune des revendications 1 a 3 caracterise en ce que 
I'analyse globale des flux est realisee a I'aide de tests d'analyse statistique 
ou protocolaires. 

5 - Utilisation du procede selon Tune des revendications 1 a 4 a I'analyse de 
donnees dans un reseau ayant le protocoie TCP/IP. 

6 - Dispositif d'analyse de flux de donnees dans un reseau de 
communications pouvant etre modelise par plusieurs couches caracterise en 
ce qu'il comporte au moins un processeur adapte a mettre en oeuvre le 
procede selon Tune des caracteristiques 1 a 4. 
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